Frame-relay networks communicate data in packets. Packet-based networks such as frame-relay and Internet-Protocol (IP) networks are not optimized to transmit voice. Various attempts to support voice over packet-switched networks exist, but not for networks that do not support FRF.12, especially where multiple access Private Virtual Circuits (PVCs) are unavailable. There are many such networks today.
Accordingly, certain multiservice nodes including software-implemented routers and switches made by leading vendors do not support voice over a low-speed communications link because they do not support FRF.12. These multiservice nodes were designed to route IP packets, as well as switch traditional frame relay, but the FRF.12 standard is not supported. An exemplary FRF.12 aspect not supported includes frame-relay reassembly: the reassembly of fragmented frames. Using FRF.12 to accommodate low-speed voice transmissions is desirous.
The Frame Relay Forum (FRF) promulgates implementation agreements, also known as standards. These implementation agreements are numbered and explain certain standards and recommendations for implementing a set of technologies. For example, an implementation agreement related to FRF.12 was written in December 1997 and entitled Frame Relay Fragmentation Implementation Agreement (implementation agreement). This and all other FRF implementation agreements are available from The Frame Relay Forum, Suite 307 at 39355 California Street in Fremont, Calif. 94538.
The shorthand reference to “FRF.12” refers to the FRF.12 protocol, which is described in the FRF.12 implementation agreement and incorporated by reference herein. Accordingly, FRF.12 is a standards-based way of fragmenting frame-relay packets.
Frame-relay networks offer many advantages including a protocol-independent data-transmission system that can communicate packets (“frames”) of data of various sizes in virtually any native data protocol. One skilled in the art would appreciate such an advantage. As explained in the 18th edition of Newton's Telecom Dictionary (Newton): an X.25 packet of 128 bytes can be switched and transported over the network just as can an Ethernet frame of 1500 bytes. However, focus for frame relay payloads has turned to IP, usually based on RFC 1490 encapsulation. Although frame-relay networks offer certain advantages, especially as single PVC access to VPN cores, there is not an accepted way to transmit voice across a low-speed link if these networks do not support the FRF.12 protocol. The industry standards prevent it.
Explained in greater detail below, a serialization delay is a window of time to prevent excessive voice-packet latency, or even packet rejection. In the prior art, the serialization delay is prevented from exceeding an accepted value, ten milliseconds, by setting the fragmentation size to a value small enough to achieve that goal. But in networks without FRF.12 support, fragmenting with FRF.12 to the necessary size will prevent any IP payloads from reaching their destination across the VPN. This fragmenting disassociates the IP header of the parent frame from the fragmented frames. The fragmented frames would be lost because the IP header is not duplicated for each frame fragmentation.
Absent the present invention, it has not been possible to accommodate low-speed voice transmission over a VPN with FRF.12 limitations that markets a single PVC logical access method, as many do. Again, many hardware providers' network components, such as virtual routers, do not currently conform to the FRF.12 standard. The current industry-recommended alternative to using FRF.12 to support low-speed voice transmission is to use multiple PVCs.
A PVC is a permanent association between two terminal devices. Newton explains: once the PVC is designed and programmed by a carrier into a network, all data transmitted between any two points across the network follows a predetermined path, making use of a virtual circuit. But many data products do not market such a use of multiple PVCs. Instead, frame relay PVC's are used as access mechanisms to reach a core VPN—giving network subscribers any-to-any connectivity with only one PVC. By implementing a single-PVC-per-site concept, these networks greatly reduce the number of PVCs that would be required to provide any-to-any, point-to-point links. Implementing a multiple-PVC scheme is typically prohibitively complex.
Beyond the complexity, another significant problem with implementing multiple PVCs is that IP networks, in general, do not use multiple PVCs, or layer-2 connections. They use a single layer-2 connection. That is, using multiple PVCs does not offer a low-speed voice-transmission solution in an IP networking (including IP-VPNs) environment. A network-based VPN service has routing and security intelligence built into the network, rather than at the customer's premises. Thus, using multiple PVCs is not a viable option for transmitting voice over a low-speed.
With no industry-recommended way to support low-speed voice, the current state of the art could be improved by providing a way to transmit high-quality, low-speed voice across existing (and future) networks that do not support FRF.12.